Spec #2405 - Manifests without installer info#6286
Conversation
This comment has been minimized.
This comment has been minimized.
* Add 'installable' - term used in NoInstaller specification * Add 'Trenly' - author name in specification * Add 'waivered' - term used in validation policy description Addresses check-spelling-bot findings from PR microsoft#6286
|
|
||
| The `NoInstaller` installer type and `InstallerAvailabilityMessage` field are introduced in **Manifest Version 1.30.0**. | ||
|
|
||
| Older clients (< 1.30.0) will not recognize `InstallerType: NoInstaller` or `InstallerAvailabilityMessage` fields because they are part of manifest version 1.30.0. The manifest validation schema enforces version requirements. |
There was a problem hiding this comment.
We should test the actual behavior to see what errors/warnings happen if we do this. We may need to consider when the right time is to roll this out into production for the community repository, and what default versions of WinGet on various OS versions will do.
There was a problem hiding this comment.
PS E:\winget-cli> wingetdev validate E:\winget-pkgs\manifests\b\Badlion\BadlionClient\3.1.9
Manifest validation succeeded.
PS E:\winget-cli> wingetdev show -m E:\winget-pkgs\manifests\b\Badlion\BadlionClient\3.1.9
Found Badlion Client [Badlion.BadlionClient]
Version: 3.1.9
Publisher: Badlion
Publisher Support Url: https://support.badlion.net/
Moniker: blc
Description: Badlion Client is a Minecraft launcher with many added features. It includes anticheat, built-in FPS boost and other mods, and is compatible with most versions of minecraft 1.7 or newer.
License: Proprietary
Copyright: © 2013-2021 ESL Gaming Online, Inc.
Tags:
minecraft
optifine
Installer:
Installer Type: noinstaller
Installer Locale: en-US
Installer SHA256: 85f8124a876d702319807b5604814c07d9099b43863f585543f2f1b1c95cdf1d
Offline Distribution Supported: false
Installer Availability Message: This is for testing only
PS E:\winget-cli> winget install -m E:\winget-pkgs\manifests\b\Badlion\BadlionClient\3.1.9
Found Badlion Client [Badlion.BadlionClient] Version 3.1.9
This application is licensed to you by its owner.
Microsoft is not responsible for, nor does it grant any licenses to, third-party packages.
An unexpected error occurred while executing the command:
0x80004003 : Invalid pointer
PS E:\winget-cli> winget -v
v1.28.240
There was a problem hiding this comment.
Looks like that path could be improved to better communicate the unknown installer type. It might be getting interrupted by a faulty assumption before hitting an existing version of that.
JohnMcPMS
left a comment
JohnMcPMS
left a comment
There was a problem hiding this comment.
As a note on the overall item, I don't think we can take this work (not the spec, the actual product change) as a contribution without internal commitment to implementing it as it will require validation updates. Part of that is expressing a clear, prioritizable problem that is being solved.
| 1. **System Components** — Windows built-in software, drivers, and OEM-installed applications often have no downloadable installer outside their original distribution channel. | ||
| 2. **Pre-installed Software** — Recognizing applications that ship with the OS or hardware allows WinGet to correlate and manage them without installation. |
There was a problem hiding this comment.
What is the scenario to have a package that was never available? I don't really want to bloat the repository with these manifests if there is no purpose. We can already discover installed items just fine, the only thing I could see is bringing consistency to their identity (if the listed name changes over time for instance). But that alone doesn't seem worth the cost of maintainenace.
|
|
||
| 1. **System Components** — Windows built-in software, drivers, and OEM-installed applications often have no downloadable installer outside their original distribution channel. | ||
| 2. **Pre-installed Software** — Recognizing applications that ship with the OS or hardware allows WinGet to correlate and manage them without installation. | ||
| 3. **Out-of-Band Distributions** — Some publishers distribute software through non-WinGet channels (corporate systems, hardware partners, distribution agreements) and want WinGet to recognize these versions for correlation and upgrade tracking. |
There was a problem hiding this comment.
This still sounds like "was never available" and thus makes it fall into my previous question.
| The field may also be specified at the root manifest level: | ||
|
|
||
| ```yaml | ||
| InstallerAvailabilityMessage: "This version has been removed due to a security vulnerability" |
There was a problem hiding this comment.
If I'm not mistaken, InstallerType can also be specified at the root and it would be reasonable to represent that in this example.
|
|
||
| For community repository submissions with `NoInstaller` installer type: | ||
|
|
||
| - A new validation rule `Validation-NoExecutables` (similar to existing validation rules) must be introduced. |
There was a problem hiding this comment.
| - A new validation rule `Validation-NoExecutables` (similar to existing validation rules) must be introduced. | |
| - A new validation rule `Validation-NoInstaller` (similar to existing validation rules) must be introduced. |
Name consistency?
| - A new validation rule `Validation-NoExecutables` (similar to existing validation rules) must be introduced. | ||
| - This rule should be auto-waivered, requiring Microsoft review for each `NoInstaller` submission. | ||
| - This ensures that community contributions using `NoInstaller` are reviewed to prevent misuse (e.g., publishers blocking inclusion for "corporate reasons"). | ||
| - Legitimate use cases (system components, OEM software, official tombstones) receive appropriate waiver. |
There was a problem hiding this comment.
I think that we need to have a solid policy on the legitimate use cases before we move forward with implementation. I don't want to end up with a scenario where no manifests are ever removed, they only become NoInstaller. The repo has already become quite large and we don't need to introduce a new rot mechanism.
| PackageName: Example Package | ||
| License: Example License | ||
| ShortDescription: Example package description | ||
| LongDescription: This version is no longer available. Please upgrade to version 3.0.0. |
There was a problem hiding this comment.
I wouldn't expect one to change the existing descriptions, that is what the availability message is for.
|
|
||
| **Behavior:** | ||
| - User on x64 system can install normally. | ||
| - User on arm64 system receives message that ARM64 is unavailable and cannot install this version. |
There was a problem hiding this comment.
This glosses over the compatibility scenarios. If we are on ARM64, the current installer selection mode would choose the NoInstaller option and then fail that way. If you simply remove the ARM64 installer, it would check if x64 is supported on the device and potentially install that one.
It feels like the NoInstaller "installers" should be intentionally pushed to the lowest ranking in the selection order to prevent a potentially compatible installer from being overridden.
One must also take care to ensure that the upgrade scenario is not impacted, but I believe that is done largely through filtering of the installers and should therefore not be impacted by the sort ordering.
|
|
||
| The `NoInstaller` installer type and `InstallerAvailabilityMessage` field are introduced in **Manifest Version 1.30.0**. | ||
|
|
||
| Older clients (< 1.30.0) will not recognize `InstallerType: NoInstaller` or `InstallerAvailabilityMessage` fields because they are part of manifest version 1.30.0. The manifest validation schema enforces version requirements. |
There was a problem hiding this comment.
Looks like that path could be improved to better communicate the unknown installer type. It might be getting interrupted by a faulty assumption before hitting an existing version of that.
|
|
||
| - No download activity for `NoInstaller` packages; user bandwidth and disk I/O are preserved. | ||
| - Install operation terminates immediately with an error message, avoiding wasted processing. | ||
| - Repo index size is minimally impacted; `NoInstaller` entries use the same schema as other installer types. |
3 participants
📖 Description
This PR introduces the specification for the NoInstaller installer type (Issue #2405), enabling WinGet to recognize and manage packages that have no downloadable installer. The specification covers the complete design for:
NoInstallerenum value inInstallerTypeEnumInstallerAvailabilityMessagefield (manifest v1.30.0) with field constraintsThe specification addresses all design feedback from PR #6157 and provides a comprehensive reference for implementation across winget-cli, winget-create, winget-cli-restsource, and winget-pkgs.
🔗 References
🔍 Validation
No validation needed — This is a specification document that describes design intent and expected behavior. No code changes, manifests, or executable artifacts are included.
✅ Checklist
📋 Issue Type